ATM originated as a telecommunication concept defined by the Comite Consulatif International Telegraphique et Telephonique (CCITT), now known as the International Telecommunications Union (ITU), and the American National Standards Institute (ANSI) for carrying user traffic on any User to Network Interface (UNI/Q.2931) and to facilitate multimedia networking between high speed devices at multi-megabit data rates. ATM is a method for transferring network traffic, including voice, video and data, at high speed. Using this connection oriented switched networking technology centered around a switch, a great number of virtual connections can be supported by multiple applications through the same physical connection. The switching technology enables bandwidth to be dedicated for each application, overcoming the problems that exist in a shared media networking technology, like Ethernet, Token Ring and Fiber Distributed Data Interface (FDDI). ATM allows different types of physical layer technology to share the same higher layer--the ATM layer.
ATM uses very short, fixed length packets called cells. The first five bytes, called the header, of each cell contain the information necessary to deliver the cell to its destination. The cell header also provides the network with the ability to implement congestion control and traffic management mechanisms. The fixed length cells offer smaller and more predictable switching delays as cell switching is less complex than variable length packet switching and can be accomplished in hardware for many cells in parallel. The cell format also allows for multiprotocol transmissions. Since ATM is protocol transparent, the various protocols can be transported at the same time. With ATM, phone, fax, video, data and other information can be transported simultaneously.
The components of the ATM header consist of the following fields. A generic flow control (GFC) field provides flow control; a virtual path identifier (VPI)/virtual channel identifier (VCI) field allows the network to associate a given cell with a given connection; a payload type identifier (PTI) field indicates whether the cell contains user information or management related data and is also used to indicate a network congestion state or for resource management (i.e., the EFCI bit which is part of the PTI field); a cell loss priority (CLP) field indicates that cells with this bit set should be discarded before cells with the CLP bit clear; a header error check (HEC) field is used by the physical layer for detection and correction of bit errors in the cell header and is used for cell delineation.
The provisioning of an ATM network connection may include the specification of a particular class of service. The following list the various classes of service currently defined in ATM. Constant bit rate (CBR) defines a constant cell rate and is used for emulating circuit switching (e.g., telephone, video conferencing, television, etc.). Variable bit rate (VBR) allows cells to be sent at a variable bit rate. Real-time VBR can be used for interactive compressed video and non real-time can be used for multimedia e-mail.
Available bit rate (ABR) is designed for data traffic (e.g., file transfer traffic, etc.) and is the class service connected with resource management. The source is required to control its rate depending on the congestion state of the network. The users are allowed to declare a minimum cell rate, which is guaranteed to the virtual circuit by the network. ABR traffic responds to congestion feedback from the network.
A fourth class of service, unspecified bit rate (UBR), is utilized by data applications that are not sensitive to cell loss or delay and want to use leftover capacity. During congestion, the cells are lost but the sources are not expected to reduce their cell rate.
ATM is a connection oriented transport service. To access the ATM network, a station requests a virtual circuit between itself and other end stations, using the signaling protocol to the ATM switch. ATM provides the User Network Interface (UNI) which is typically used to interconnect an ATM user with an ATM switch that is managed as part of the same network.
The signaling utilized in ATM networks is defined by a set of three protocols: UNI signaling (ITU standard Q.2931), Service Specific Coordination Function (SSCF/Q.SAAL1/Q.2130) and Service Specific Connection Oriented Protocol (SSCOP/Q.SAAL2/Q.2110). The signaling layer performs the setting up and tearing down of ATM connections that run end to end through the ATM network. The other layers, which are collectively known as the Signaling ATM Adaptation Layer (SAAL), are responsible for providing the signaling layer with a reliable service over which messages generated therein may be transported.
The signaling module provides a means for defining a large number of parameters that specify the destination address, protocol selections and quality of service of the call that the user wishes to set up. In operation, the signaling module performs a function roughly analogous to the process of dialing in the context of the normal telephone network, i.e., it establishes the connection through the network to the end user before the data transfer phase begins or before speech begins, in the case of the telephone network analogy.
Unlike the normal telephone system, however, ATM networks are required to set up and tear down a large number of calls per second. For example, it is not uncommon for a single processor to be required to handle 300 to 500 calls per second. The speed with which these calls are set up and torn down is crucial for the users of an ATM network and hence for the manufacturers of ATM switches and other related network equipment.
Currently, it is customary for vendors of ATM equipment to purchase implementations of the UNI signaling protocols, since their basic functionality is standard and their implementation is quite complex. The UNI signaling protocol software implementations provide users, i.e., the ATM equipment manufacturers, with an API to all the primitives (standard functions) contained in the signaling software. The API function calls included in the software define how the signaling functions are evoked, in addition to defining the complete functional capabilities of the UNI signaling protocol software.
The majority of signaling implementations provide an API sufficiently flexible that provides the user with control over all parameters that are associated with the new call that needs to be set up. This is attractive since it provides the user with maximum flexibility, providing the user with run time control of all related parameters. However, a disadvantage of this approach is that there are a large number of parameters that can be associated with any particular call and encoding them all during run time is a time consuming process. This limits the number of calls per second that these signaling software packages can handle which often is in the range of only 30 to 50 calls per second.
The problem described above can be illustrated using a real world example. One of the most common ATM applications is LAN Emulation (LANE). The LANE is a module of code that resides conceptually above the UNI signaling module, i.e., the LANE is a user of the signaling stack. The LANE standards (version 1.0) currently in effect do not offer a way of specifying quality of service when establishing new connections. Therefore, LANE implementations provide identical values for the vast majority of parameters associated with each ATM connection that it sets up. This, however, creates a situation whereby the signaling software spends a considerable amount of time encoding identical parameters for each call that it sets up. This is both wasteful and costly to the users of the signaling software.
Another example is the way in which incoming calls are handled in either switches or end user devices. In the typical case, an incoming SETUP message is decoded and all of the Information Elements (IEs) are examined with most being used without change. For example, a switch would handle an incoming call request by examining the requested IEs in the SETUP message received, modifying (or adding) one or two IEs but would leave the remainder of the IEs unchanged. Here again the situation is that most of the incoming IEs are decoded, processed and then encoded with exactly the same values.